---title: "Transcrição da Prova Teórica 1" matricula: "20243003394" nome: "João Vítor Marques Costa" disciplina: "Gestão de Projetos de Software (GPS)" avaliacao: "Prova Teórica 1" data: "19/10/2026" nota_total: 19.8 legibilidade_global: "92%" classificacao: "Alta Legibilidade (90-100%)" observacoes_caligrafia: "Excelente caligrafia cursiva a lápis grafite, diagramação organizada de EAP e matrizes. Respondeu com profundidade técnica às 5 questões, demonstrando alto domínio em DoD, CoQ, segurança e comunicação híbrida." format: html: toc: true theme: cosmo pdf: documentclass: scrartcl papersize: a4 geometry: - margin=20mm --- # Avaliação Teórica 1 — Transcrição de Respostas ## Questão 1 — Ciclo de Vida e Fundamentos de Projetos * **Legibilidade da Questão:** 94% * **Gravidade de Leitura:** Normal ### 1.1 Projeto vs. Operação * **Resposta Manuscrita:** > Ele é um projeto, pois um projeto tem um início, meio e fim com um escopo de tempo definido e com uma entrega determinada. Já a operação é algo executado, um exemplo seria a criação de uma funcionalidade na Netflix que analise com IA os filmes mais vistos entre o público jovem. ### 1.2 Análise de Trade-off no Triângulo de Ferro * **Resposta Manuscrita:** > Primeiro poderíamos ter menor cargas de teste porém estaríamos com mais chances de erros e com a regra dos 1:10:100 poderíamos ter um tempo e custo muito maiores com o retrabalho. Também poderíamos fazer a entrega parcialmente completa e depois trazermos as demais partes e com isso o tempo e o custo aumentariam significativamente. ### 1.3 Ciclo de Vida do Projeto e Abordagem * **Resposta Manuscrita:** > O ciclo de vida tendo 15 aulas (15 semanas) e cada Sprint sendo 2 semanas teríamos 7 sprints que é uma abordagem híbrida, que temos uma grande quantidade de sprints de entrega, porém com essas duas semanas para cada o volume de trabalho se torna mais leve e maleável. --- ## Questão 2 — Escopo, EAP e Gestão de Backlog * **Legibilidade da Questão:** 92% * **Gravidade de Leitura:** Normal ### 2.1 Estrutura Analítica do Projeto (EAP) * **Diagrama / Elemento Visual:** ```text Nível 0: AGENTE DE CÓDIGO SOCRÁTICO Nível 1: [FRONTEND] | [BACKEND E LÓGICA] | [GESTÃO DE PROJETOS] Nível 2: - de Frontend: [Definição das core lines], [Criação da Tela de chat] - de Backend e Lógica: [Criação do código de resposta], [Proteção da chave API] - de Gestão de Projetos: [Estruturar o git], [Criação dos DOCS. Ex: PC] ``` * **Resposta Manuscrita:** > No nível 0 é o nosso software, no nível um pegamos as grandes bases como o back e front e a gestão de projeto. No nível 2 são as pequenas entregas e a partir disso a EAP funciona pelas pequenas entregas do nível 2, depois grandes do nível 1 até chegar ao nível 0. ### 2.2 Especificação de Issues de Backlog e Estimativas * **Resposta Manuscrita:** > 1.1.2 Criação da tela de chat -> título > descrição: Deve ser criado a interface de chat via streamlit que já aceite a integração com a API Gemini. > critério aceitação: A interface deve se comunicar bem com a API trazendo um tempo de resposta de no máximo 7 segundos. > - Tempo estimado de 3h. > *(Omissão da segunda issue comparativa).* ### 2.3 Milestones vs. Sprints no Modelo Ágil * **Resposta Manuscrita:** > Não, pois as milestones são os grandes marcos de conclusão como a aceitação por parte do professor agente da nossa interface da tela de chat. Já as sprints são 'pequenos' marcos completos como a produção de uma tela completa (ex: a tela de interface de chat). > O Kanban sem sprints pode ser aceito quando temos um projeto menor com menos marcos principais sem uma definição de tempo estipulada. --- ## Questão 3 — Qualidade e Engenharia de Software com IA * **Legibilidade da Questão:** 92% * **Gravidade de Leitura:** Normal ### 3.1 Definição de Pronto (DoD) e Pipelines de CI/CD * **Resposta Manuscrita:** > A definição de pronto vem depois que todos requisitos foram atendidos, todos os riscos foram verificados e todas as comunicações feitas além dos testes. No CI acontece a compilação e os testes se der ERRO é barrado no MERGE REQUEST e o CD recebe e faz o envio. No nosso cenário ela não está pronta pois mesmo que passe pelo CI/CD significa que apenas compilou mas não significa que foi aprovado por todas as verificações do professor agente. ### 3.2 Custo da Qualidade (CoQ) * **Resposta Manuscrita:** > a) prevenção, para que mais de uma pessoa conheça e entenda o código > b) avaliação, para verificar e avaliar a qualidade do código > c) falha externa, passou pela equipe e chegou ao usuário > d) falha interna, pego ainda na mão dos dev's. > O mais alto é o D [referindo-se ao evento de produção de (c)] pois a falha externa que foi pego pelo usuário já passou por todas etapas sem ser pego e agora terá um retrabalho e um custo maior. ### 3.3 Heurística 1:10:100 e Testes em Software com IA * **Resposta Manuscrita:** > A regra dos 1:10:100 é que se for identificado durante o início do projeto seu custo é 1, se for identificado durante os testes o custo é 10 e se passar por tudo e ser identificado em produção pelo usuário ele é 100. Em projetos com IA temos um limite que conseguimos verificar com esta regra através das diretrizes de prompt fazendo testes e a treinando, porém ainda é de sua natureza obedecer os prompts maliciosos do usuário. Essa regra é muito importante ser seguida pois se não fizermos todos os testes de segurança corretamente podemos ter um gasto muito maior do que seria apenas investindo em segurança pois agora será necessário um retrabalho no projeto. --- ## Questão 4 — Gestão de Riscos e Segurança * **Legibilidade da Questão:** 92% * **Gravidade de Leitura:** Normal ### 4.1 Classificação do Evento e Matriz de Riscos * **Diagrama / Elemento Visual:** * Marcou no quadrante Crítico ("Aqui estaria o risco"). * **Resposta Manuscrita:** > Era um risco que poderia acontecer. Um problema é algo que já ocorreu e agora será corrigido. Ele é um risco crítico pois a probabilidade de acontecer é alta e seu impacto no projeto é gigantesco, devido a isso deve sempre ter uma grande cautela para não commitar a chave, e agora eles devem gerar outra chave para o projeto. ### 4.2 Resposta a Incidentes e Defesa em Profundidade * **Resposta Manuscrita:** > Primeiramente eles devem trocar a chave API e apagar a exposta. Após isso devem reportar e dizer qual ação foi tomada, registrar o contexto, justificativa e consequências no ADR e adicionar uma segurança para a nova chave criando um arquivo .env para ela e protegendo para não ser enviada ao git. ### 4.3 Modelagem de Ameaças em IA e Documentação Decisória * **Resposta Manuscrita:** > Causa -> Prompt pedindo a resposta completa do código que o professor disse que não valia nada e era apenas para ler. Probabilidade -> alta; Impacto -> alto, pois conseguiu burlar uma premissa básica do agente. Mitigação e contingência -> fazer uma nova bateria de testes e treinamento do agente para evitar novos eventos com esses. > Eu usaria uma ADR pois lá justificamos tudo desde a causa, nossa ação e as consequências. Com isso damos um melhor respaldo do ocorrido. --- ## Questão 5 — Comunicação, Partes Interessadas e Conflitos * **Legibilidade da Questão:** 90% * **Gravidade de Leitura:** Normal ### 5.1 Canais de Comunicação e Rastreabilidade Decisória * **Resposta Manuscrita:** > As comunicações síncronas são melhores para as comunicações e entendimento para alinhar pensamentos, porém podem deixar as informações informais. As assíncronas são boas pois resolutivas e direto ao ponto, porém podem deixar interpretações subjetivas. O ritual seria a combinação híbrida entre os dois, onde tem as issues com o que deve ser feito mas também as reuniões para o alinhamento dos pensamentos assim a comunicação seria ideal e teria toda uma formalidade necessária para o projeto. ### 5.2 Engajamento de Partes Interessadas (Poder × Interesse) * **Diagrama / Elemento Visual:** * **Manter Satisfeito:** P (Professor) * **Gerenciar de Perto:** A (Alunos) * **Monitorar:** E (Equipe), PR (Provedor) * **Manter Informado:** C (Coordenação) * **Resposta Manuscrita:** > Como o professor é cliente e patrocinador preciso manter ele satisfeito. Já o aluno é necessário gerenciar de perto para saber o que ele acha do projeto e o que ele está tentando fazer nele. Para o aluno que temos podemos propor analisar a frequência que ele utiliza o Agente e conteúdo que ele mais teve dúvida e com isso gerar um relatório geral para passar ao professor patrocinador para que ele veja os resultados e também a coordenação do curso. ### 5.3 Resolução de Conflitos e Modelo de Thomas-Kilmann * **Resposta Manuscrita:** > Nós precisamos fazer o modelo SMART para que o projeto atenda todas as necessidades e que não adianta ele ser extremamente técnico se o aluno não adotar ele em sua rotina. Uma resposta longa e detalhada pode trazer preguiça ao aluno e um estouro de informações, para o aluno entender deve ser algo objetivo e didático. Quanto as respostas curtas e socráticas é uma boa ideia, mas para que ela seja efetiva deve haver um treinamento extensivo do agente para evitar a alucinação.